home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9504 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.1 KB
  1. Path: anvil.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 1 Mar 1996 11:41:08 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4h7jskINNnph@anvil.ugrad.cs.ubc.ca>
  8. References: <00001a73+00002504@msn.com> <1996Feb22.005518.13396@leeweyr.sccsi.com> <4gvrffINNlqo@anvil.ugrad.cs.ubc.ca> <4h5hgj$vpd@tomquartz.niestu.com>
  9. NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
  10.  
  11. In article <4h5hgj$vpd@tomquartz.niestu.com>,
  12. Chip Richards <chipr@niestu.com> wrote:
  13.  >Sigh.
  14.  >
  15.  >In article <4gvrffINNlqo@anvil.ugrad.cs.ubc.ca>, Kazimir Kylheku writes:
  16.  >
  17.  >   What is intrinsically unsafe about C?
  18.  >
  19.  >Lots of things.  How much time have you?
  20.  >
  21.  >My current employer produces industrial process control systems.  Ada and C
  22.  >were considered for the implementation back in 1981, but neither was
  23.  >sufficiently well-supported on the "mandated" hardware, so an extended Pascal
  24.  >was chosen instead.  That decision has paid off repeatedly in terms of
  25.  >reliability, which translates directly into a reduction in certain unpleasant
  26.  >side-effects such as down-time, explosions, lawsuits, and even injuries and
  27.  >death.
  28.  >
  29.  >The most common failure for one of these control computers is "range check",
  30.  >which is completely missing from C.  Certainly, a C coder *could* add range
  31.  
  32. The C states that accessing arrays past their boundaries is undefined behavior.
  33. Some implementations offer range checking, though it's not required.
  34.  
  35.  >checks, but so could those Pascal programmers.  However, if they had, the
  36.  >compiler-generated checks would not be triggered.  C programmers, feeling
  37.  >"close to the hardware" and so often paying homage to the god of "efficiency",
  38.  >fail to put checks in just as often, but their compiler provides no option for
  39.  >backing them up in those instances.
  40.  
  41. This is false. There are compilers which offer range checking. In a situation
  42. where safety-critical software is designed, such a compiler should be used.
  43. No feature of the C standard is incompatible with an implementation that offers
  44. range checking. The only fault is that it is not made a mandatory
  45. implementation feature. And if it were, the lack of an official validation
  46. suite would still take away from your confidence.
  47.  
  48.  >There actually was an over-zealous vice-president who, upon learning that the
  49.  >most common error was a range check, suggested that all the range checks be
  50.  >removed from the code, thus preventing the majority of errors!  Cooler heads,
  51.  
  52.  
  53.  >who understand that it is much better (given the control system architecture)
  54.  >to simply stop processing than to continue processing with erroneous data,
  55.  >prevailed, and the range checks are still shipping.
  56.  >
  57.  >   I could write a strict, standard-conforming, anally-retentive program in
  58.  >   any language that could kill people (maliciously, of course).
  59.  >
  60.  >So you could.  So could I, so could anyone.  What is much more the treat (and
  61.  >much more difficult) is to write a program (*any* program) which does *not*
  62.  >kill people, even when it is entrusted with their safety.  The skill lies not
  63.  >in writing a dangerous program intentionally, but in *not* writing such a
  64.  >program *unintentionally*.
  65.  
  66. This is a matter of religious debate. The programming tools can catch some
  67. trivial mistakes (such as range overruns), but many other mistakes are not
  68. easily caught. I just found a bug in a project that I'm working on which was
  69. simply an incorrect calculation. It could easily have been written in Ada, and
  70. wasn't all _that_ trivial to find.
  71.  
  72. I bet I could get a Fortran programmer to write Ada code that looks like Ada
  73. but is really Fortran in disguise. :)
  74.  
  75.  >Oh, this is rich!  Have the words "implementation defined" been driven from
  76.  >that spec?  Have they at least been eliminated from the *important* areas,
  77.  >like bitfields?  Formality of specification and predictability of results are
  78.  
  79. Bitfields are important? They are rarely used. Some aspects of bitfields are
  80. well-defined. They serve a purpose, which is compact storage of small integers
  81. at some computing cost. There is a way to use them properly, in a well-defined
  82. manner. Using bitmasks defined as symbolic constants is also well-defined and
  83. portable.  The unsigned long type is guaranteed large enough to hold 32 bits.
  84.  
  85. The ULONG_MAX constant defined in the <limits.h> header file is at least
  86. 2^32-1, which makes unsigned long suitable for storing a bitfield of size 32.
  87.  
  88.  >attributes that all languages possess to smaller or greater degree; I would
  89.  >venture to say that C++ exceeds C in these areas, and Ada exceeds C++.  And
  90.  >Ada could itself stand some work.
  91.  >
  92.  >   I don't think you can say the same for Ada or C++.
  93.  >
  94.  >Well, obviously *you* can't say that about Ada or C++, but only because you
  95.  >are underinformed.  I can say i.t fine:  Ada95 is *already* an ISO standard,
  96.  
  97. I have apologized for that error already.
  98.  
  99.  >and C++ is well along its way to becoming one.
  100.  
  101. Which is far from actually being standardized. Until I can actually go out and
  102. put my hands on the document, it is ``vaporware''.
  103. -- 
  104.  
  105.